fix(codegen): root_reload's cost cap counts root loads, not derived values - #9854

The bug

MAX_BLOCK_LOAD_PRODUCT guards the reachability walk in root_reload::apply_to_function. That walk runs once per groups entry — one per root load; the module's own comment says so ("Grouping by root load also puts the cost back at O(blocks × loads)").

The check multiplied by values.len() instead. Since #7664 extended a recipe through pure bit ops, values counts every derivation as its own Reloadable, so on a wide function it is several times the group count. The pass therefore declined on functions whose actual cost was well inside the bound.

Why declining is not safe

The constant's comment read:

Above the cap the function keeps today's IR — the pass is an improvement, not a correctness precondition, so declining is safe.

Under the native root lowering that is false, and it is why this went unnoticed. When the pass does not run, nothing else re-reads the slot. A receiver read out of its root and unmasked to an i64/double is exactly the "case 2" shape this module's header documents: RS4GC relocates the addrspace(1) load, but the unmasked copy that actually crosses the call is beyond its reach.

Where it was found

Claude-of-Duty's Arm.constructor:

With the pass declined, this.upper = buildSleeve(...) stored through a stale receiver. Under PERRY_GC_PROTECT_FROMSPACE=1:

[gc-fromspace-protect] FAULT: signal 10
  This address is RETIRED FROM-SPACE. The evacuating minor moved or
  freed the object here and the holder kept the pre-collection address.
  last-known object: obj_type=2 size=184
  perry_..._Arm_constructor  <-  Viewmodel_constructor  <-  WeaponSystem__init

The faulting instruction is the inline class-field store's own shape check, ldurh w8, [x19, #-0x6], where x19 is the receiver unmasked from callee-saved x22 — loaded before bl buildSleeve and never relocated. Without from-space protection it degrades silently: the write lands in the dead copy, so the later read of this.upper returns undefined and THREE reports Object3D.add: object not an instance of THREE.Object3D. undefined.

The change

One term. groups is built before the cap check and the product measured against it. The bound is unchanged at 8M.

A function that genuinely exceeds blocks × groups still declines and can still carry a stale register. That residual risk is real; the constant's doc now states it instead of denying it.

Test

the_cap_counts_root_loads_not_derived_values replicates the existing masked_receiver shape across 1100 blocks, each with a MAX_RECIPE-length derivation, sized to clear the cap by the old metric (~9.7M) and sit an order of magnitude inside it by the new one (~1.2M).

Verified in both directions:

A note on the checker

scripts/gc_root_dominance_check.py --stale-registers --moving-only does not flag this shape. On the faulting module it reported 0 stale uses of this kind (17 total, all source=global). So it cannot be relied on as a guard here — worth a separate look.

Verification

• cargo test --release -p perry-codegen — 1912 passed, 0 failed
• cargo test --release -p perry-runtime — 2878 passed, 0 failed (on the earlier base)
• End to end: the reduced reproducer goes 138 → 0 with no from-space fault, and Claude-of-Duty's native build now gets past WeaponSystem.init (3 weapons · 136.8k tris viewmodel) and renders.

Summary by CodeRabbit

• Bug Fixes
  • Improved code generation for functions with many control-flow blocks and derived values.
  • Prevented valid functions from being rejected by an overly restrictive reload-cost limit.
  • Ensured stale values remain correctly reloaded across operations that may trigger garbage collection.
  • Added regression coverage for large functions involving masked value derivations and collecting calls.